@UglyKidJoe I have been using OpenHAB and MQTT for a number of years now. The reason for using MQTT and not just a serial connection from the MySensors GW is partly the flexibility as many have stated previously here. Easy to test, using e.g. the mqtt.fx tool. If you want to know what is going on you simply connect to the MQTT stream and "snoop" on the messages. Another reason is that I am running three geographical sites on one OH installation. OH is running on a NUC at my home. There is also an MQTT GW here. Two other My Sensors MQTT-GW are running remotely in two summer houses. The three GW connect over internet to a cloud-based MQTT broker and OH connects to the same broker. In that way I do not have to open any ports into my home network for access should I have had a local MQTT-broker at home.

My memory is sh*t.... i even replied to this relevant post! http://forum.mysensors.org/topic/812/realtimeclockdisplaysensor-ino-no-fetch-time-from-controller/6

@gregl I have used this procedure a few times: Define for example a V_VAR1 message for the query (or use any other suitable message type depending on purpose), Make a MQTT binding for this message i Openhab (for example bind it to a switch, a number or whatever fits the purpose) Make a rule in Openhab that reacts on this incoming message ("When Item xxxxx received update then ......) Fix whatever logic is needed in this rule so you can send the queried info back to the sensor. If no existing binding is suitable you can of course define a V_VAR2 message (or use other type which fits) for the return message. In the "Incomingmessage" function use whatever logic is needed to decode the returned message. Reason for choosing a custom type of message (like a V_VAR2) for sending the info back is of course that it is easy to sort it out from the stream entering the incoming messages function. If you have no other incoming messages or the logic for the queried info already is in place then you do not have to think about this. Hope the explanation is understandable, if not please revert.

@gadu I'm sorry to bring up a post from the dead, but could someone point me in the right direction to find the MQTTGateway file/files for the RaspberryPI, i can only find the arduino ones and the possibility of a RPi one, here, but with no MakeFile to compile it.... Just a little background info and an ongoing topic located here at the forums of what I'm attempting to do and what is happening: Link

Thanks for the suggestion. I found another solution. I have the item like this: Switch Incalzire_Releu_GF_Living1 "Incalzire Releu Living 1" <heating> (Incalzire) {mqtt=">[mysensor:MyMQTT/3/1/V_HEATER_SW:command:ON:1],>[mysensor:MyMQTT/3/1/V_HEATER_SW:command:OFF:0],<[mysensor:MyMQTT/3/1/V_HEATER_SW:command:MAP(1on0off.map)]"} and in 1onoff.map i have: **1=ON 0=OFF 1.4.1=REQUEST ** And then I have a rule: rule "SW1 Persist" when Item Incalzire_Releu_GF_Living1 received command then if (receivedCommand == "REQUEST") { sendCommand(Incalzire_Releu_GF_Living1 , Incalzire_Releu_GF_Living1.state); } end In the arduino code for the relay I have in the setu() this code. **void setup() { gw.begin(incomingMessage, AUTO, true); gw.sendSketchInfo("Relay Control", "1.0"); for (int sensor=1 ; sensor<=NUMBER_OF_RELAYS;sensor++) { gw.present(sensor, S_HEATER); gw.request(sensor, V_HEATER_SW,0); } }** So whenever gw.request is called the idem receives an update with 1.4.1 that is resolved by the rule to the actual state of the switch in openhab. Like this, when arduino starts, the relays will be swiched ON as per the actual state of the switch.